Businesses' ever-increasing reliance on information and the computing systems that produce, process, distribute, and maintain such information in its various forms, puts great demands on techniques for efficiently accessing that information. Business organizations can produce and retain large amounts and varieties of information (and normally do so, in fact). Searching for specific data has thus become an integral part of many enterprise applications.
Various business units within an enterprise can maintain data using a variety of searchable objects. A searchable object is a representation of a set of one or more joined tables that contain data. A searchable object can have table-like behavior such as an ability to query a set of records within those joined tables. Commonly, the data types within a searchable object are complex and varied.
In today's world, search has become an integral part of enterprise/customer relationship management (CRM) applications, for example. In a typical CRM application used by communications companies, for example, thousands of call center agents create/update millions of records on a daily basis. In such an environment, a typical call center agent performs numerous search operations during a workday in order to get to the correct record(s) to assist their customers quickly and efficiently.
Additionally, it is common for an enterprise to run multiple applications (e.g., an enterprise resource planning (ERP) system, CRM application, human resource management system (HRMS) application, and the like), possibly from different vendors catering to various needs of the enterprise. Moreover, each of these applications may need to use different search engines.
A centralized search system can be used to coordinate searching for desired data among various locations where data may be stored. It is important to optimize the search system's configuration in order to get precise, relevant and accurate search results.
In an attempt to provide such advantages, older search systems employ search techniques that tightly integrate searching mechanisms with the user interface. These mechanisms are neither flexible nor configurable, and provide only a proprietary user interface for searching a database. Existing search architectures therefore do not provide the ability to modify the system to employ a new search engine. In other words, a user cannot, with minimal effort and downtime, replace an existing search engine with a new one. In present systems, the search engine is tightly woven into the architecture stack. Hence, even a small change, such as adding a new field to a search category, forces the application server to be shutdown, thereby potentially affecting the productivity of tens of thousands of users.
A typical change requires at least the following operations:
1) Modify the search category, as necessary
2) Shutdown the server
3) Re-compile various portions of the system
4) Deploy new module(s) and
5) Restart server
Listed below is a list of some of the difficulties facing such earlier search architectures:                1) Inability to modify system to employ a new search engine.        2) Inflexibility: Modification of the searchable fields and indexable fields is not possible without bringing down the server. The architecture and implementation are tightly woven, and closely integrated with a specific search engine. Inability to allow integration of a new search engine with the existing search user interface is also problematic.        3) Database Dependence: Database (DB) support is provided by the search engine. For every new DB to be supported by the enterprise application, the search engine is required to support DB connectors for the new DB. Hence, if the underlying search engine is upgraded to a newer version of open database connectivity (ODBC) drivers or cannot support a database, the search capability of the application is severely compromised. (ODBC provides a standard application programming interface (API) method for using database management systems (DBMS).)        4) Pull-Model Indexing: Existing search engines pull the data from a data store, and hence, there is little or no control over the indexing process.        5) Non-existent Incremental Indexing: Due to the use of a pull-model, there is no automatic incremental indexing. An administrator is required to manually start full indexing or do a manual refresh process from time-to-time. Thus, the data seen by users is typically stale.        6) Non-intuitive user interface (UI) for search results: The search results rendering is done in a proprietary list applet, making it less user-friendly.        7) Tight integration with a single engine.        8) Complex configuration and server down time required        9) No search category grouping.        10) Difficult to integrate additional data connectors.        11) Completely dependent on search engine database support.        12) Complex customization.        13) Redundancy in executing repetitive searches.        
Therefore, it is desirable to have a mechanism that permits search access to a number of data stores (of varying types), without the need for costly downtime of the enterprise-wide search system. Moreover, the system should allow for multiple search engines, again without the need for extensive modification of the existing search architecture. Further still, such a system should provide for efficient searching by allowing a user to specify a number of data stores, rather than only one, or all, such data stores, when performing a search.
The use of the same reference symbols in different drawings indicates similar or identical items.